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ABSTRACT 


As broadband connections to the home become more prevalent, through Digital 
Subscriber Lines (DSL) and cable modems, students and faculty will desire to access the 
NPS intranet via these new means instead of their 56K modems. The introduction of 
these new technologies will require NPS to re-evaluate how to allow remote access to 
their internal resources in a secure way, while still allowing for the use of broadband 
technologies. 

This thesis will examine the alternative methods for implementing VPNs, from 
simple use of Point to Point Protocols (PPP) to high end specialized internet appliances 
and gateways. Pros and cons of each will be discussed. A mock-up of the school’s 
network will be created to test each of the discussed methods. Final recommendations 
will be made for a model that can be used by the NPS to implement a VPN. Also 
discussed will be how that model may be altered to fit other commands throughout the 
US Navy who desire similar secure remote access to their internal network resources. 

It should be noted that the thesis will concentrate on remote secure access to an 
internal network from a single remote host more than on the VPNs’ additional ability to 
remotely connect two or more secure networks together, such as can be found in a 
business to business (B-to-B) environment. 
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I. 


INTRODUCTION 


A. BACKGROUND 

Today’s computers have become a replacement for older storage mediums such as 
notebooks and hardbound encyclopedias. People now store their information on digital 
media in their desktop computers or on file servers located on an internal network. The 
convenience of digitally storing this information in a central location has the drawback of 
not always being immediately available if it is stored on a remote system. A potential 
solution to this is allowing remote access to this information from another host system, 
such as a laptop when on travel, or from a person’s home computer. 

This is a very common situation. Students and faculty at the Naval Postgraduate 
School (NPS) require such remote access to their digitally stored information, as well as 
the network internal to the school, herein referred to as the campus intranet. Many 
professors now post their course wares on the intranet for student access, and ask students 
to place assignments in designated public folders on the intranet. Many military web 
sites require the user to be on another military domain (i.e., .mil) to gain complete access 
to their sites. Being on the campus allows individuals to easily access these resources, 
but there are times when people are away from the campus and still desire, or even 
require, access as if they were on the intranet. This could be for something as simple as 
working on an assignment from home, or as complicated as being on travel in a foreign 
country and requiring access to important research material. Allowing remote access 
enables these individuals to seamlessly become part of the intranet. 
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NPS has met the needs of faculty and students by allowing dial-up access to the 
intranet. Modem pools allow an individual to dial directly into the network, authenticate 
themselves, and become part of the intranet. This solution has been well received in the 
past, but new broadband technologies such as Digital Subscriber Lines (DSL), cable 
modems, and broadband wireless connections are changing, the current equation. These 
broadband technologies use a new type of modem that cannot be used to dial-in to the 
intranet via the existing modem pool. They work over the Internet Protocol (IP) and 
require access to the intranet directly from the Internet. This is not to say that most of 
these users do not have access to modems and telephone lines. Most users still do, and 
they still dial into the intranet, but this does not allow them to utilize the larger 
bandwidth, and therefore faster speeds, afforded them by broadband technologies. 

Older modem pools are also limited in a variety of ways. Users are limited by the 
number of available modems, a problem exemplified by America On Line when they 
could not meet their expanded user base due to their limited number of modems. 
Download and upload speeds for information transfer is very limited by both the lower 
speeds of older analog modems and telephone line conditions. There is also an inherent 
lack of security of dial in connections, since all data is passed “in the clear” 
(unencrypted) and can be easily tapped. Finally, there is the issue of maintaining a large 
numbers of modems on the campus, as well as the costs incurred by remote users who 
must call in via long distance phone calls. 

An emerging solution that can be used to address these concerns is a Virtual 
Private Network (VPN). Used to create encrypted “tunnels” between two hosts, a VPN 
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allows users to access intranets from across the Internet, using their access method of 
choice, whether it be broadband or dial-up through a local Internet Service Provider 
(ISP). Connection to the intranet is via the campus’ connection to the Internet, 
eliminating the requirement to connect using the campus analog modem banks. By using 
any access to the Internet, and a VPN, many of these previously discussed limitations are 
overcome. Data is protected while passing over the Internet by encrypting, all £he data 
before it leaves the remote host, and is then decrypted by the local host on the intranet, 
and vice-versa. Once authenticated, a user can also access the campus intranet just as if 
they were on campus. They can even be set up with a local NPS IP address, allowing 
them access to those restricted military domains referenced earlier. 

Installation of a VPN on the NPS would also have the added benefit of 
positioning NPS to become part of the Navy and Marine Corps Intranet (NMCI), a secure 
Department of the Navy (DON) wide computer network. The NMCI is designed to allow 
its 450,000 plus members to securely exchange data, voice and video from their desktops 
(Peniston). This extranet will be based upon a VPN solution, and interconnect both its 
physical infrastructure and personnel through this method of secure tunneling. With a 
VPN solution in place, NPS can more easily manage its transition into the NMCI. 

B. PURPOSE OF RESEARCH 

The intention of this thesis is to create a model for implementing a VPN on the 
NPS campus. By reviewing emerging VPN technologies, it will discuss methods that 
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allow secure access to the Naval Postgraduate School’s Intranet. It will propose a plan 
encompassing hardware and software solutions, as well as other relevant issues. 

Specific research questions the author sets out to answer are: 

1. Why do students and faculty desire and/or require remote access to the campus 
intranet? 

2. What are the methods that can be used to gain secure access to the intranet? What 
are the advantages and disadvantages of each? 

3. What are Virtual Private Networks (VPNs) and how can they be used to aid in 
obtaining secure remote access? 

4. Specifically, what are the emerging technologies associated with VPNs, and how 
are they being implemented? 

5. What are the different authentication methods that can be used to authenticate a 
user? What are the advantages and disadvantages of each? 

6. How do IPSec, PKI, and specifically DoD PKI, impact implementing a VPN at 
the NPS? 

7. Can the model developed for the NPS be modified for use throughout the Navy? 

C. SCOPE, METHODOLOGY, LIMITS, ASSUMPTIONS 

This thesis is limited in its scope. It is meant to create a set of recommendations 
on how the NPS could implement a VPN. It includes multiple VPN architectures, 
leaving it up to the NPS to decide which architecture best suits their security and 
accessibility requirements. 
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It concentrates on the “road warrior” perspective of a single remote host that 
requires access to a protected intranet via the Internet. It does not cover, nor is it 
intended to cover, the concept of securely connecting remote networks via the Internet to 
create an extranet. Though this is a significant feature of a VPN, it is not within the 
scope of this thesis. The thesis is also intended to be a general model for other Naval 
commands to implement their own remote access features on their VPNs.' Though 
general recommendations will be included, it is expected that other commands may have 
slightly different architectures; the concepts and recommendations should be extensive 
enough for each to interpret the work in accordance with their own networks, and adjust 
as necessary. 

The research methodology used in writing this thesis included a combination of 
methods. Extensive literary research was first performed using the resources listed in the 
bibliography. Additional education on the subject was obtained from attending the 
following conferences: DON Public Key Infrastructure (PKI) and Virtual Private 
Networking Technology Workshop, April 1999; O’Reilly Open Source Software 
Convention, July 2000; SANS Parliament Hill 2000, Aug 2000; USENIX, August 2000; 
VPN Con, September 2000; and SANS Network Security 2000, September 2000. While 
on travel, the author was also able to visit and interview with the Information Technology 
(IT) staff at Bentley College, where their VPN was illustrated and extensive discussion 
on authentication methods lead to significant insight into potential solutions. Hands on 
experience was gained by working with the NPS Network Operations staff in 
understanding the current network architecture of the NPS intranet, and from creating a 
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custom research lab that was a mock-up of the intranet. This mock-up was then subjected 
to the installation of different VPN technologies, including a TimeStep© 7520 gateway 
appliance. 

There are certain assumptions the author made in writing this thesis. Though 
there will be an extensive review of key concepts, it is expected that the reader still has a 
basic understanding of how networks work. This includes understanding the Internet 
Protocol (IP) and functions of basic network components such as routers and firewalls. 


D. THESIS ORGANIZATION 

The author has segregated this thesis into four chapters. Chapters I and II are 
meant as an introduction to the concepts that will be covered more in-depth later in the 
thesis. These chapters should be used as background information for those readers 
unfamiliar with VPNs and the components that go into creating secure connections. 
Chapter III contains the heart of the thesis, discussing VPN implementation 
methodologies and specific concerns with each. It is here that pros and cons associated 
with remote access methods are covered. Chapter IV encompasses the author’s 
recommendations on actual implementation considerations for the NPS. It also discusses 
conclusions and possible areas for further research. 
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H. BACKGROUND INFORMATION AND KEY CONCEPTS REVIEW 


A. VPN OVERVIEW 

Virtual private networks are used to create secure connections between two hosts 
over an unsecured medium. This medium can be a public medium such as the Internet, or 
a private medium, such as a company’s Wide Area Network (WAN). Its purpose can be 
to allow users access to information that normally would not be available to them since 
they are not on the internal network, or to secure communication on the network they are 
sharing. When VPNs are used to gain access to a network, they enable you to act as if 
you are actually on that network, giving you the same access to resources you would 
normally have if you were there. When used on an internal network, a VPN ensures 
privacy across the internal network by encrypting data between specific hosts or network 
segments. 

There are three varieties of VPN architecture: network-to-network, host-to-host, 
and host-to-network (Brenton and Elfering, p. 7). All three are based upon the same 
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technology, the difference is solely in how that technology is applied. 

VPNs can be used to create an extranet. This is where a private network is 
selectively opened to designated parties outside the network. This access to the network 
is normally privately held among specific members of a firm or institution, where the 
information is proprietary and closely held (Maier, pp. 6-8). This thesis concentrates on 
the concept of creating an extranet, specifically in the form of a host-to-network secure 
VPN. This type of extranet is commonly referred to as the “Road Warrior” scenario in 
tribute to those members of an organization who perform their work away from the 
office, but yet still require access to those resources found on the company’s intranet. 

VPNs should not be confused with WANs and Remote Access Services (RAS). 
VPNs are similar to WANs and RAS in that they connect remote users to private 
network, but there are differences that should be pointed out. Both WANs and RAS are 
more of a physical connection mechanism, where a VPN is more of a logical use of a 
physical connection. WANs normally consist of two or more networks connected via 
dedicated and private lines supplied by a third party, such as the telephone company; 
VPNs utilize an existing connected public medium to create logical tunnels instead, 
encrypting IP datagrams which may traverse the same connections a WAN may reside 
on. Where leased lines may give the illusion of security, for one can never be truly sure 
where your data traverses once it leaves your site, VPNs use their encryption ability to 
ensure security over any medium. Traditional RAS services are similarly composed of 
banks of modems using incoming, on-demand telephone lines for connecting remote 
users, again leaving the illusion of security; VPNs connect via an already established 
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public network access point, such as through a router or firewall, ensuring confidentiality 
via encryption. Instead of dialing in to a central RAS point, the users of a VPN dial their 
own Internet Service Provider (ISP) and connect to the network using their secure 
method or protocol, such as SSH, PPTP, L2TP, etc. (Erwin, Scott and Wolf, pp. 45-46) 



confidential communication “tunnel.” These methods ensure that the properties of 
authentication, confidentiality, and integrity are met. Each of these aspects is developed 
in more detail later in the chapter. 

The beneficial characteristics of VPNs have lead to early adoption of the 
technology by many companies and to projections of its substantial growth. Such benefits 
include the flexibility of being able to quickly create tunnels to connect networks, verse 
having to wait to install leased lines, as well as not having to pay for their lease. VPNs 
also benefit from the confidentiality gained through the encryption of its data, versus the 
illusion of confidentiality found with leased lines, as well as the ability to secure data 
while it transits even an internal network. It is projected that companies can expect 
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savings of 20% to 47% of their WAN costs through releasing leased lines and 60% to 
80% of corporate costs for remote access dial-up, recouping monthly charges for 1-800 
phone numbers and other phone charges for remote access (Bourne, p. 2). VPNs also 
allow for the use of private, non-routable IP addresses across the Internet, as well as 
allowing legacy equipment to operate over extranets with non-routable protocols, through 
encapsulation. These technologies will allow the average number of telecommuters to 
grow by 184% between 1999 and 2001, as well as a growth in the number of mobile 
workers by 72% in the same time frame (Newbridge). Chris Brenton in his VPN and 
Remote Access book states that VPN technology is expected to expand 300-1000% by 
2003, and Newbridge projects that VPNs will grow at a compound annual growth rate of 
$32 billion in the same period. 

There are additional benefits for the military as well. For such organizations as 
the United States Navy, the VPN’s ability to ensure object level security of the data gives 
the added benefit of no longer having to find ways to keep the network backbone secure. 
These organizations have been forced to pay an exorbitant amount of money to ensure 
their private networks remain private, and have had to adopt an assortment of 
implementation methods in doing so. VPNs can aid in allowing them to consolidate 
these solutions by investing in 100% insecure, off-the-shelf IP “plumbing” for all 
communications, including such expensive systems as ship-to-shore communications, 
and concentrate on securing the bits of data, not the physical, link-level infrastructure. 
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B. BASICS OF ENCRYPTION, AUTHENTICATION, AND INTEGRITY 

1. Confidentiality through Encryption 

The concept of the VPN uses encryption to provide communication 
confidentiality. Encryption is the conversion of data into a protected form for 
transmission over an untrusted medium to a trusted party. Encryption is meant to be a 
computationally easy conversion of data to and from cipher-text (encrypted data) by the 
trusted parties, but computationally difficult for an untrusted party who intercepts the 
data. Note the subtlety in this concept: encryption is not meant to be impossible to break, 
but is meant to be too hard or take too long to get at what is hidden in the cipher-text. 
Encryption only needs to be strong enough to keep the data protected for the lifetime of 
the value of the data. Once the data no longer has value, the encryption of it become 
unnecessary. (Erwin, Scott, and Wolfe, pp. 22-23) 

2. Authentication 

Before establishing a secure connection, VPNs strive to authenticate both hosts 
that are attempting to create the tunnel. This is like asking both ends to “log-in” with 
each other, usually using a two tier system: what you have and what you know. Each end 
validates itself by having something unique, such as a piece of client software with an 
embedded shared secret key or maybe a digital certificate, and also with something they 
know, such as an additional user ID and password or pass-phrase. More specifics of this 
concept are given later in this chapter, but it is important to the general concept. By 
authenticating, both ends ensure that no one untrusted can connect to the network. This 
keeps intruders out, and helps prevent session hijacking (when a third party takes over 
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your session, like a terrorist hijacking a plane) by revalidating users throughout the 
course of an established session (Brenton and Elfering, p. 46). 

3. Integrity 

Even if a VPN is utilizing encryption, and both parties have been authenticated, 
you may still require positive proof that the original data being sent as cipher-text was not 
changed. Integrity can be designed into your VPN solution through the use of hashing 
and encryption, all of which is covered in more depth in the Encryption Algorithms 
section of this chapter. When integrity is enforced, it can also aid in the process of non¬ 
repudiation. This is when authentication, integrity, and encryption are combined into a 
method that proves a message was sent by a specific person, and was not altered in any 
way. 


C. VPNS AS A SYSTEM 

In its most basic form, a VPN is the use of mathematical algorithms by a set of 
procedures in an end product’s implementation. Cryptographic algorithms are used to 
convert data via encryption and in a process called hashing. These algorithms are then 
used in a set of procedures, such as PAP and IKE, to create authentication and integrity of 
the data. These procedures are then standardized for their implementation, as found in 
the protocols PPP, PPTP, L2TP, and IPSec. Finally, these implementations are placed 
into a company’s end products, the VPNs themselves, and take a variety of forms such as 
Microsoft’s PPTP implementation, embedded VPN products within vendors’ firewall 
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products, and gateway appliances such as Alcatel’s TimeStep product line. Each of these 
areas is covered in much more depth throughout the rest of this thesis. 

1. Tunneling 

Tunneling is the common term for encapsulating individual packets on a packet- 
switched network and is the basis upon which VPN implementations are based. It takes 
the original packet and encapsulates it into a new packet with new header information, 
making the original packet the payload of the new packet. Tunneling is extremely useful 
for carrying non-routable protocols such as NetBIOS over a WAN using TCP/IP. In the 
case of DP Sec, IP packets are being tunneled in new IP packets for protection, if 
encrypted, or possibly to use non-routable IP addresses over a public network. There is 
tremendous potential in using private EP address spaces, such as 192.168.X.X and 
10.X.X.X, since all that is required is one public address used at the gateway. With IP 
addresses becoming scarce in IP Version 4 (IPv4), and most home users with broadband 
access using private addresses to share their Internet connections in their homes, this type 
of encapsulation will become quite common. A caveat to this is that Internet Protocol 
Version 6 (IPv6), if ever adopted, has been crafted to allow for IPv4 encapsulation and 
vice versa, as well as an expanded IP address space of “one undecillion addresses 
[translating] to more than a thousand IPv6 addresses for every square meter on the 
surface of the Earth” (Walton, p. 6). The IPSec hosts usually perform the encapsulation, 
whether it is the laptop of the road-warrior, or the gateway of a network. Additional 
information on IPSec tunneling can be found in RFC 2003 IP Encapsulation within IP. 
(Murhammer, et. al., pp. 49-50) 
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The following sections go into greater detail on cryptographic algorithms, the 
frameworks they are used within, and the implementations of IPSec and authentication. 
They are meant to develop a greater understanding of the VPN as a system, giving the 
reader the building blocks for understanding VPN protocols and methodologies covered 
in later chapters of this thesis. 

D. ENCRYPTION ALGORITHMS 

In its simplest form, a cryptographic algorithm is a “procedure that takes the plain 
text data and transforms it into cipher-text in a reversible way” (Snyder, p. 13). 

There are two methods used to encrypt data. The first is based upon a secret 
shared or common key. This method is called symmetric key cryptography. The second 
is based upon a mathematical algorithm that allows for the generation of two keys; each 
only able to decrypt messages encrypted by its mate. This latter method is the basis for 
many procedures found in VPN implementations in use today, and is called asymmetric 
key cryptography. 

Characteristics of a good cryptographic algorithm include: 

• The algorithm is known and subject to analysis and no practical 
weaknesses have been discovered 

• Given the clear-text (input to the algorithm) and the cipher-text (output 
of the algorithm), the key can still not be computed 

If the algorithm is published or known, not secret, it provides stronger encryption 
than “security through obscurity” where it is assumed just because an algorithm is not 
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known, it is secure (Snyder, pp. 20-21). The encryption itself depends on two 
mechanisms: the encryption algorithm, which provides the mathematical conversion 
mechanism, and a key, which provides the randomness to the final cipher-text when used 
by the encryption algorithm (Bird, p. 22). 

1. Symmetric Key Cryptography 

Symmetric keys have long been used throughout history, starting from the 
time of Caesar. This method of a shared secret key has even been at the foundation of our 
military security since the military’s introduction of cryptography. As its name implies, 
the system uses a single key shared between two hosts, and the users of the system 
closely hold the only key that can decrypt and encrypt. To be used, both parties must 
agree on the key before any secure communication can take place between (Murhammer, 
et. al., p. 29). Therefore, a system must be developed to distribute and protect these 
shared secret keys. 



Symmetric Key 


Figure 2-3. Symmetric Key Encryption/Decryption 

The most common types of symmetric key algorithms are block algorithms, 
which work on blocks of bits of the clear-text message at a time. Block ciphers modes 
include Electronic Code-book Mode (ECB), where each block of cipher-text is encrypted 
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independently, and Cipher Block Chaining (CBC), where the result of the previous block 
is used in the encryption of the next block. Well known block ciphers include: Data 
Encryption Standard (DES) with a 56 bit key length; triple-DES (3DES), where DES is 
applied three times to the clear-text; and International Data Encryption Algorithm 
(IDEA) which uses 64 bit blocks and 128 bit keys. IDEA is most notably used in the 
software application Pretty Good, Privacy (PGP). Though DES is an older standard, 
developed in the 1970’s, it is still widely used today. (Murhammer, et. al., pp. 29 - 30) 

2. Asymmetric Key Cryptography 

Where symmetric key cryptography requires sharing a single key that must be 
kept secret from non-trusted parties, asymmetric key cryptography allows users to 
generate their own pair of mathematically related, yet individual, keys. Then one of these 
keys (called the public key) is shared publicly and used to encrypt messages back to them 
by any other party. They keep their other key (called the private key) private only to 
themselves and use it to decrypt any messages sent to them. Since the keys are 
complementary, but not identical, they cannot be used to perform bi-directional 
encryption/decryption, meaning once something is encrypted with one key it can not be 
decrypted by that same key; only its mate can decrypt it. This is important because once 
a message is encrypted with a publicly shared key, no one, not even some other party that 
has a copy of the public key, can decrypt the message. An encrypted message is then 
safe to transmit over insecure or untrusted mediums; even if an untrusted party intercepts 
the message, that party cannot decrypt the cipher-text with the publicly available key. 
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Figure 2-4. Asymmetric Key Encryption/Decryption 
3. Hashes 


A hash is a one-way algorithm used to create a unique fixed length cipher-text of 
a message, or more simply put, it’s a formula to convert a message of any length into a 
single string of characters called a message digest. It’s considered a zero-key encryption 
algorithm; where symmetric key encryption uses a single key for encryption/decryption, 
and asymmetric key encryption uses a second key for decryption, a hash cannot be 
decrypted, so it has no key. Think of it in terms of mashing a potato: once a potato is 
mashed, reconstructing the original potato is rather difficult. 

Hashes are mainly used as a fingerprint of the clear-text. Hashing algorithms are 
made to be collision-resistant, meaning it’s highly improbable that two different clear¬ 


text messages will produce the same hashed value. This is what provides for message 
integrity as discussed earlier. When a hash of the clear-text is sent with the encrypted 
message, the message once decrypted can be re-hashed with the same algorithm, and the 
hashes compared. If they are the same, then the message has not changed. 

An extension to the concept of hashing is Message Authentication Code (MAC). 
This is when you either concatenate a key to the clear-text before hashing it, or when the 
hash algorithm can take a key as a second input (the message being the first input) to the 
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hash. Simply put, if you encrypt a hash, it becomes a MAC; if you concatenate a secret 
key to a message and then hash it, it becomes a MAC (Murhammer, et. al., p. 37). A 
sender utilizes a MAC hash by including the session key with the message when hashed, 
so when the receiver rehashes the concatenation of the message with the session key, it 
ensures authentication when the two match. The greatest value of a MAC is its ability to 
provide message integrity, without the intensive computation required to encrypt a whole 
message. 

Hashes can also play a role in digital signatures. This is where the hash of the 
original message is encrypted with the private key of the sender. Once the message is 
received, the public key is used to decrypt and get the original hash value and is then 
compared to a new hash of the decrypted message. Since the encrypted hash can only be 
decrypted with the public key of the original sender, and only the sender has access to 
their own private key, it ensures that sender is who they say they are. 

The most widely used hash functions are MD5, created by Ron Rivest, and Secure 
Hash Algorithm 1 (SHA-1), adopted by the National Institute of Standards and 
Technology (NIST) and the National Security Agency (NSA). MD5 produces a 128-bit 
fixed length hash and SHA-1 produces a 160-bit fixed length hash. It should be noted 
that neither of these takes a key as an input parameter, and therefore cannot be used for 
MAC calculations, unless the key is concatenated to the message. 

Hashed Message Authentication Code (HMAC) makes a hash function a MAC. It 
applies the hash twice in succession. Here, MD5 can be used on a concatenated 
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message/key combination, then the results of that hash are concatenated again with the 
key, and hashed a second time. (Murhammer, et. al., pp. 29-30) 


E. PROCEDURES AND FRAMEWORKS FOR USING ENCRYPTION 

ALGORITHMS 

1. Diffie-Hellman 

Diffie-Hellman utilizes asymmetric keys (i.e., one public, one private), to create a 
unique symmetric key. It is used extensively in key creation in VPNs, and is worth 
further explanation here. 

Diffie-Hellman allows two hosts who share no common keys to create a shared 
secret key by using asymmetric keys. It sounds complicated, but really isn’t. The 
following diagram and detailing of steps will clarify it. 


1. P,G 

3. X 

4. A=G X mod P 
6. K=B X mod P 



2. P,G 


Alice 




Bob 


Cracker 

Figure 2-5. Diffie-Hellman Key Creation 


3. Y 

4. B=G y mod P 
6. K=A y mod P 


This diagram shows how once two hosts have established communications, they 
can, with no prior shared information, exchange data that is susceptible to interception 
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and still create a shared secret that cannot be reversed engineered by the information that 
was intercepted. It starts in step one by host one, Alice, choosing a large prime number P 
and an integer G. In step two, those numbers are shared with host two, Bob, and since 
they traverse the public medium, we assume bad guy Cracker can see them as well. The 
third step is for both Alice and Bob to chose a random number. Alice chooses X, and 
Bob chooses Y. These numbers are their “Private keys” and .not shared.. In the fourth 
step, both Alice and Bob compute their “Public keys” by raising integer G to the power 
of their private key and performing modulus arithmetic on the product with the large 
prime number P. So Alice’s public key is A=G mod P, and Bob’s public key is B=G 
mod P. In step five, Alice sends Bob her public key A, and Bob sends his public key B to 
Alice, and since it again traverses a public network, we assume Cracker gets these as 
well. At this point Cracker has P, G, A, and B. The final step to creating the symmetric 
shared secret key is to compute it by raising the received public key by the power of the 
private key and taking the modulus with P. So Alice computes the shared secret key K 
by computing K=B X mod P, and Bob computes the same shared secret key K by 
computing K=A Y mod P. Now they have a shared key that they can encrypt and decrypt 
messages with (since it is a symmetric key), and Cracker can not crack it, since it is 
computationally infeasible to compute both Alice’s and Bob’s private keys, even given 
the information Cracker intercepted. 

The reason this works is due to the simple mathematical principles that 
((G)Y=((G) y ) x and K=(G) XY mod P (remember, X and Y are the private keys that never 
traverse the untrusted medium). 
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2. Public Key Infrastructure (PKI) 

PKI is the infrastructure used to crea‘te, distribute, and revoke the public key of an 
asymmetric key pair by a central authority, called a Certificate Authority (CA). The CA 
is responsible for creating public key certificates for each person who uses the CA’s 
service. Each certificate includes not only a user’s public key, but also some form of 
distinguished name to uniquely identify the individual, a validity period, and some form 
of the CA’s digital signature that is used to verify that the certificate is authentic (Snyder, 
p. 39). Though a certificate may sound imposing, it can be thought of being similar to a 
driver’s license or passport; it’s a form issued to you by a trusted authority that can aid in 
validating who you are, similar to your license and passport issued by your state or 
federal government. 

It should be noted that for smaller VPN implementations, the full-blown 
infrastructure of a PKI in not necessarily required. Pretty Good Privacy (PGP) is an 
example of an asymmetric key infrastructure that doesn’t require a CA, but can still be 
used for encryption and authentication. The use of PGP in this way assumes a secure 
method is established for issuing public keys, such as handing a copy of a public key on 
disk to a co-worker, so they know it is from you. In this case, the manageability is very 
similar to using local host files instead of a Domain Name Service (DNS) for correlating 
a computer Media Access Control (MAC) address to an IP address; its fine in a very 
small implementation, but the overhead becomes non-trivial when needed to scale to 
larger implementations. 
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3. Internet Key Exchange (IKE) 

In order for hosts to create the secure tunnels that make up a VPN, they must 
create secure associations, authenticate each other, and exchange the keys they will use 
for the encryption of their data. This is done with the Internet Key Exchange (IKE) 
protocol. IKE is responsible for providing authentication of all peers, handling the 
security policy negotiations, and controlling the exchange of keys (Scott, Wolfe and 
Erwin, p. 36). It is used to create an initial encrypted session, enabling the exchange of 
the information required to make the final encrypted session. 

This protocol originates from the combination of two other protocols: the Internet 
Security Association and Key Management Protocol (ISAKMP) and Oakley. IKE 
inherits its security association (SA) and key management (but not key exchange) from 
the ISAKMP protocol, and supports the pre-shared key, digital signature, and public key 
encryption methods of authentication. Oakley was originally the key exchange protocol 
used for VPNs and lent its abilities to IKE. Oakley is vital to security, being that no 
matter how strong the encryption and authentication algorithms are, they are worthless if 
your key is compromised. (Murhammer, et. al., p. 71) 

IKE is performed in two phases: phase one and phase two. In phase one, two 
hosts establish a secure connection, called the IKE SA. Authentication is either 
incorporated into phase one with digital certificates, or takes place between phases one 
and two, kind of phase 1.5, with extended authentication techniques (Bird, pp. 89-90). In 
phase two, the final keys used for encryption will be generated, and the IPSec SA will be 
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negotiated. After these two phases, the IPSec SA has been created and is used for all 
further communication, thereby making the secure “tunnel.” 

In the first phase, IKE chooses between two modes to complete the IKE SA: Main 
mode and Aggressive mode. During the second phase, IKE uses its third mode, Quick 
mode, to negotiate the final IPSec SA. If extended authentication is required, another 
step is inserted between these two to authenticate the user,-, . . , 

a. Main Mode 

To create an IKE SA, Main mode will take the two hosts through three 
two-way exchanges, totaling six steps. The first exchange, being steps one and two, the 
hosts agree on basic algorithms and hashes that will be used throughout the remaining 
four steps. In steps three and four, they prepare to create an encrypted tunnel by using 
Diffie-Hellman, exchanging the necessary items to create their shared secret key, as well 
as their digital certificates if they have them. Steps five and six complete the Diffie- 
Hellman exchange, leaving each with the shared secret with which to encrypt the rest of 
the data that they will share to finish the IKE and create the IPSec SA. (TimeStep, pp. 
20 - 21 ) 

b. Aggressive Mode 

This mode is used to accomplish the same end result as Main mode, but it 
does so in only three steps instead of six. This mode is quicker, but at the sacrifice of not 
protecting the identity of each host that is not normally divulged until the encrypted fifth 
and sixth steps of Main mode. This is accomplished by sending the IKE SA proposal, the 
Diffie-Hellman information, digital certificates if used, and the ID packet all in the initial 
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exchanges between the two hosts during steps one and two, instead of breaking them 
down into the six steps. The last step of this mode is just a confirmation exchange. 
(TimeStep, p. 21) 

c. Extended Authentication (XAUTH) 

If the hosts chose not to use digital certificates to authenticate each other, 
then authentication must take, place before continuing on to phase two,, Quick mode. 
Here, an extra set of exchanges takes place between the hosts to authenticate each other 
using an extended authentication method such as RADIUS. For more information on 
authentication, see the Implementation of Authentication section later in this chapter. 

d Quick Mode 

Quick mode is used in phase two to negotiate the final IPSec information 
between the now-authenticated and secure hosts. This is accomplished using the current 
IKE SA to ensure security of the exchange. The end result of this phase is the creation of 
the final IPSec SA and the generation of fresh keying material, including the symmetric 
kev used for all further encryption between the hosts . 

To generate the new SA, the initiating host sends the Quick mode 
message, protected by the IKE SA, requesting the new IPSec SA. This request includes 
which Security Parameter Index (SPI) to use in future communications to it. This SPI, 
combined with the destination IP address and protocol to be used, uniquely identifies a 
single IPSec SA . It is important to remember that these SAs are only for one-side of the 
conversation; it takes two SAs for bi-directional communication. Security Parameter 
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Indexes are covered in greater detail in the next section of this thesis. Implementation of 
the IPSec protocol. 

e. Perfect Fonvard Security (PFS) 

PFS is an option in generating the final set of symmetric keys in Quick 
mode. It is used to create a key that does not have any information derived from or 

depending on the previous key used. . _ . 

When the final keys are to be created, there are two ways this can be 
done. Quick mode can be set to create the new key by just hashing the original key used 
during IKE phase one. Though this is simple and fast, the problem is that if your original 
key is later cracked, it is a simple step to hash that cracked key, giving the cracker your 
next key. To keep this from happening, Quick mode can use PFS to initiate a new Diffie- 
Hellman key exchange to create a new key each time one is needed. This use of Diffie- 
Hellman ensures that even if the original key is cracked, it gives no information on the 
next key. The cracker would then have to go back and crack the new key instead of just 
being able to hash the previous key value to find the new key. The down side to this is 
that it takes more time, steps, and computational power to create new Diffie-Hellman 
keys then is does to just hash the previous one, so security needs to be balanced with 
performance to meet each individual communities needs. (TimeStep, pp. 19-23) 

F. IMPLEMENTATIONS OF THE INTERNET SECURITY PROTOCOL 
(BPSEC) 

The IPSec protocol is a suite of protocols combined to create a security standard 
by the Internet Engineering Task Force (IETF). Its purpose is to act as an extension to 
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the Internet Protocol (IP), providing security services, since IP was not designed with 
security in mind. One of the goals of the IETF was to create an implementation that 
would be an interoperable, vender neutral standard. It also provides a framework that 
decreases implementation flaws by allowing for the adoption of new implementations 
that are compliant with the standards. The use of a framework like this allows 
independence from specific algorithms, locking system thinking into the standard. 

It consists of three components, including encryption algorithms, key 
management procedures, and authentication implementations. These general components 
define the architecture of the protocol, making it so that new algorithms and methods can 
be added to the framework with very little work and having little effect upon previous 
implementations. (Erwin, Scott, and Wolfe, p. 33) 

EPSec supports two modes, transport mode and tunnel mode; consists of two 
protocols, the ESP protocol and the AH protocol; and uses the Internet Key Exchange 
(IKE) to determine authentication methods, security associations, and to agree upon key 
generation and key rotation techniques. (Erwin, Scott, and Wolfe, p. 33) 

1. Transport Mode 

Transport mode consists of securing a packet’s payload through one of the two 
security protocols, while leaving its packet’s IP header information untouched. An IP Sec 
header is placed inside of the IP datagram packet, after the original IP header but before 
the payload, and the payload can be either encrypted or in the clear, depending on the 
security protocol chosen. 
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An example of when this type of mode would be used is when information on an 
internal network requires authentication or encryption, but capturing the source and 
destination addresses do not give away any vital information, since it is internal to the 
network anyway. If you wanted to protect those machine addresses, say across a public 
untrusted network (so an interceptor can not determine the address of your mail server), 
you would use tunnel mode. 

2. Tunnel Mode 

Tunnel mode encapsulates the original packet as data within another packet. The 
source and destination addresses in the outer packet correspond to the VPN device 
involved, not the specific host. This encapsulation secures not only the packet payload, 
such as done in transport mode, but encapsulates the entire packet with a new header. 
Again, the packet can be either encrypted or in the clear, depending on the security 
protocol chosen. 

An example of when tunnel mode would be a preferred choice is when you are 
using private, non-routable addresses over a WAN, or you want to protect your internal 
address information when a packet transits a public, untrusted network. 

3. IP Protocol 50 Encapsulating Security Payload (ESP) 

ESP can be used to provide encryption, integrity checking, and/or authentication 
to an IP datagram. The set of desired services is selected upon negotiation of the SA. It 
is performed on each individual packet, on a per-packet basis. Both the integrity and 
encryption aspects are optional, and either or both can be selected for use. If both are 
selected, the receiver of the packet must first authenticate the packet, and only if it 
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authenticates, will the packet be decrypted. Integrity check and authentication methods 
must be chosen so that they complement each other. The encryption algorithm used is 
independent of whatever choice is made for integrity and authentication. (Murhammer, 
et. al., pp. 56-57) 

4. IP Protocol 51 Authentication Header (AH) 

AH is used to provide integrity and authentication, ,b.ut not encryption, to an IP 
datagram. It is used to authenticate the packet source and ensure that the packet has not 
been altered during transmission. AH is performed on each individual packet, on a per- 
packet basis. The data authentication resides in the Integrity Check Value (ICV), inside 
the AH Header. It is produced using the algorithm negotiated during the SA, and is 
usually one of the following: HMAC-MD5-96, HMAC-SHA-1-96, Keyed MD5, or 
Keyed SHA-1. (Murhammer, et. al., pp. 51-53) 


Encapsulation Mode 
Security Protocol 

Transport Mode 

Tunnel Mode 

ESP 

Encrypts only the IP 
packet’s payload, places an 
ESP header between the 
untouched IP header and the 
encrypted payload and/or 
authenticates the packet 

Encrypts the entire original 

IP packet, places an ESP 
header between the new IP 
header and the encrypted 
original IP packet and/or 
authenticates the packet 

AH 

Authenticates the entire IP 
packet, places a AH header 
between the untouched IP 
header and the unencrypted 
payload 

Authenticates the entire 
original IP packet, places an 
AH header between the new 
IP header and the 
unencrypted original IP 
packet 


Table 2-1. Matrix of Encapsulation Modes and Security Protocols 
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Figure 2-6. Effects of Encapsulation Modes and Security Protocols on IP Packets 

(Murhammer, et. al., and pp. 54-61). 
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5. Security Associations (SA) 

An SA is a logical security connection between two IPSec systems. SAs are 
negotiated when IPSec hosts create their connection, and take the form of: 

<Security Parameter Index, IP Destination Address, Security Protocol> 

a. Security Parameter Index (SPI) 

A unique 32-bit value used to identify the SA. It is carried in the header 
of the security protocol, and selected by the destination system during SA establishment. 
(Murhammer, et. al., p. 48) 

b. IP Destination A ddress 

Is the IP address of the destination host. 

c. Security Protocol 

Either ESP or AH. 

SAs define a security association in only one direction, to the destination. Since 
communication is a bi-directional activity, two SAs must be established during an IPSec 
session, one in each direction. (Murhammer, et. al., p. 48) 

6. SA Bundle 

Since an SA can only be based upon a single Security Protocol, ESP or AH, if the 
IPSec session requires both, an SA Bundle must be created. SA Bundles are two SAs 
defined in each direction, establishing a total of four SAs for the IPSec session. This is 
seen most often when a mobile host needs to create an AH SA between itself and the 
network gateway, and a nested ESP SA extends to the host behind the gateway. 
(Murhammer, et. al., p. 48) 
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7. Security Policy Database (SPD) 

SPD is a database of the available security policies that can be used to negotiate 
an SA. It contains an ordered list of policy entries that two hosts will compare to 
determine what security policy they will use to establish a connection. The SPD must 
specify the security services provided, protocols employed, algorithms used, etc. It can 
be thought of being similar to a rule base for a packet filtering firewall or an access 
control list in a router. (Murhammer, et. al., p. 48) 

8. Security Association Database (SAD) 

The SAD is a listing of all active SAs. It contains the parameter information 
about each SA, such as the Security Protocol, SPI, protocol mode, and the SA lifetime. 
(Murhammer, et. al., p. 49) 

G. IMPLEMENTATIONS OF AUTHENTICATION 

Part of the IPSec protocol suite is the support for authentication. Ensuring a VPN 
validates a host is actually a vital part of the process. So the protocol has been designed 
to support multiple validation procedures. Also note that this discussion is about 
validating a both hosts and people. This is because a VPN can be set up between two 
hosts, such as gateway VPN appliances, that have no “person” attached, but yet their 
identity must also be authenticated. 

In the implementation of IPSec, authentication takes place while the final VPN 
session tunnel is being set up by the IKE exchange. It takes place either with digital 
certificates during phase one of the IKE exchange, or between phases one and two with 
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extended authentication, XAUTH. It is also at this stage where if authentication fails, the 
tunnel is broken and the final SAs are not created. 

There are quite a few authentication techniques available, and the list is changing 
all the time, so for the purpose of this thesis, the following four frameworks will be 
considered main stream and covered: X.509 digital certificates; and the extended 
authentication procedures LDAP, RADIUS, and Kerberos. , 

1. ISO X.509 Digital Certificates 

This standard is the most highly recommended implementation for authentication 
in a VPN. It is also the most complicated to manage and implement. 

A trusted third party called a Certificate Authority (CA) is responsible for issuing, 
validating, and revoking certificates for individuals or hosts. These certificates act like 
passports, aiding, with the use of your signature via your private key, in the validation of 
who you are. Each certificate is unique, containing a users public key, some form of 
distinguished name to uniquely identify the individual, a validity period, and some form 
of the CA’s digital signature (using the CA private key) which is used to verify the 
certificate is authentic (Snyder, p. 39). 

The actual authentication takes place when one host, we’ll call him Bob, receives 
something from the other host, who we will call Alice, that has been digitally signed by 
being encrypted with Alice’s private key. Once Bob decrypts the message with Alice’s 
public key, he knows its from Alice, and knows its Alice’s public key, because that key 
has been certified by the CA. Alice is now authenticated to Bob, and the procedure must 
be done in the opposite direction to authenticate Bob to Alice. 
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2. Lightweight Directory Access Protocol (LDAP) 

LDAP is type of phone book white pages used to locate specific host information, 
including host identity and authentication information. It is lighter subset of the X.500 
Directory Service protocol. Its strength lies in its ability to be easily searched for the host 
you are looking for, and its ability to catalog and cross-reference hosts by logical 
identities like business organization or geographic location.., It is being , widely 
implemented natively in many key products, including Netscape, Microsoft’s Active 
Directory, and even in Novell’s and Cisco’s products. (Whatis?com, “Lightweight 
Directory Access Protocol”) 

3. Remote Authentication Dial In User Service (RADIUS) 

RADIUS is a protocol for exchanging information between a RADIUS server and 
a RADIUS client. Its main purpose is to provide authentication, authorization, and 
accounting for remote access users when they connect to a network. It can act as 
middleware for older authentication techniques, allowing for the continued use of legacy 
authentication systems. 
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When used with a VPN, RADIUS either authenticates hosts using its own 
authentication services, or acts as a middleman between the VPN gateway and another 
authentication server such as Microsoft’s Primary Domain Controller. In the later 
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Figure 2-7. XAUTH Authentication with RADIUS Server and NT Domain Controller 


situation, the VPN gateway informs the RADIUS server it needs to authenticate a user. 
The RADIUS server then tells the VPN what to ask for (e.g., user name and password), 
and how to send that information back (e.g., hash the password). The RADIUS server 
then passes that information onto the domain controller. If the information validates the 
user (i.e., the user name and hash of the password corresponds to what is in the domain 
controller’s security database), the domain controller informs the RADIUS server that the 
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client has authenticated. The RADIUS server then informs the VPN that the user has 


authenticated, and the VPN continues with the IPSec process, going into Quick mode. 

4. Kerberos 

Kerberos is a network authentication protocol created by the Massachusetts 
Institute of Technology (MIT). It provides secure authentication based upon a 
principle’s (i.e., user’s) knowledge of a password that the user must present. These 
passwords are stored on the Kerberos server 

Kerberos is based upon a shared secret cryptography that is used to authenticate a 
host to a Kerberos server, called a Key Distribution Center or KDC for short. The KDC 
uses an Authentication Server (i.e., Service) to handle the actual authentication process. 
(Baker, pp. 3-9) 

The importance of Kerberos to this thesis is that it will be running natively on 
Microsoft’s Windows 2000 products and could be a prime player in the authentication 
techniques used by Microsoft. 

H. NAVAL AND MARINE CORPS INTRANET (NMCI) 

The last concept to be covered on the background information for this thesis is the 
NMCI. In the last few years, the Navy, through the guidance of the Space and Naval 
Warfare Systems Command (SPAWAR), has been developing a plan to create the 
world’s largest purpose-built network. This network would interconnect all Naval and 
Marine Corps information assets under one network. It would become a massive intranet 
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that would span the globe, allowing over 450,000 users to exchange data from their 
desktops. It is projected to cost billions of dollars over a five-year period. (Peniston) 

The relevance of this massive network to this thesis is two fold. First is that most 
of its backbone will be the public Internet itself, or at least routable to the public Internet, 
with the security of the data enforced through VPN connections. Naval information assets 
may become inter-networked over a public infrastructure, and sites will depend, on being 
able to create host-to-host, host-to-network, and network-to-network connections 
securely with VPNs. Remote access for the road-warrior will become the norm, and 
demand for secure remote access will only grow. This thesis will help in mapping the 
Navy’s future implementations of remote access through VPN technology. The other 
relevance of this thesis to the NMCI is the hope it will aid the Naval Postgraduate School 
(NPS) with its transition onto the NMCI. 
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m. REASONS AND METHODS FOR IMPLEMENTING A VPN 


A. THE NEED TO REMOTELY ACCESS THE NPS INTRANET 

Certain information resources are only available from on the NPS intranet. 
Specifically, users gain access to programs that are loaded on machines and servers 
available only on the intranet, and that are protected from further distribution (i.e. 
copying to ones home computer) by its copyright. Files, such as a user’s data, may reside 
on their home directories located on the central file servers, and some research resources 
are limited to the intranet, such as programs found at the school’s library. There is also 
those times where a user must reside on a “.mil” domain to access certain military 
resources over the Internet, such as downloading the latest virus protection from the Navy 
INFOSEC site. Currently, it is only possible to gain access to these resources by either 
being directly connected to the campus intranet or dialed in to the network. This thesis 
recommends implementing a third option, that of a VPN for broadband users. Once 
connected with a VPN, all these services become available to the broadband user from 
his home. 

The implementation of the VPN itself is really just an extension of the dial-in 
resources being made available to broadband users. It can also be viewed as being in 
direct support of the school’s Policy on Appropriate Use of the Naval Postgraduate 
School Computing and Information Systems, NAVPGSCOL INTRUCTION 5230.4B. 
The purpose of this instruction is to establish the appropriate use of NPS computing and 
information systems, and states : 
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In consideration of its primary educational mission, NPS 
authorizes use of its computing and information system resources for all 
purposes reasonably related to graduate education and research; to 
intellectual and scholarly inquiry; to the NPS military mission; and to the 
general professional interests and growth of its faculty, staff, and students. 
Faculty, staff, and students are encouraged to make maximum use of these 
resources for expanding their professional horizons, and for increasing 
their knowledge, skills, and ability to contribute to the NPS and to the 
community at large. (NAVPGSCOLINST 5230, p. 2) 

So the issue becomes one of balancing the remote access needs of the faculty, 
staff, and students, with the security requirements imposed by those responsible for doing 
so in support of these resources. This becomes a sensitive issue because ease of usability 
and access is usually at the expense of stricter security. A primary example of this trade¬ 
off is that if our systems were not hooked up to the Internet, then they could not be 
exposed to hacking from outsiders, but this would be at the expense of not allowing 
access to all the resources that can now be found on the web. This chapter of the thesis 
attempts to review the options available for remote access, summarizing the advantages 
and disadvantages of each, in hopes that doing so will aid these decisions makers in their 
future decisions on remote access. 


B. WHAT IS CURRENTLY AVAILABLE AT NPS FOR REMOTE 
INTRANET ACCESS 

Before additional options can be reviewed, it is prudent to review what is 
currently available for remote access to the NPS intranet. This section does not 
necessarily deal with the broadband issues of access, but deals instead with the dial-in 
access being used today, and the protocols used to do so. 
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NPS offers a dial-up service to the faculty, staff, and students, with both a local 
number and a toll-free (1-800) number. These users are given a typed out procedure on 
how to configure their computer with a dial-up connection to the NPS Remote Access 
Server (RAS). The procedure describes how to configure the Microsoft Client and Dial¬ 
up Adapter, as well as mapping a drive to their home directory on the file server, and how 
to set up Microsoft Exchange mail client to work from their home computer. 

The school has set up a modem bank of 92 modems to handle these incoming 
dial-up connections. These modems are 56Kbps V.90 compliant, and have a utilization 
rate of around 15%, with an average of 10 to 15 simultaneous connections at any given 
time. They authenticate users by connecting to either the Microsoft Primary Domain 
Controller (PDC) or one of the Backup Domain Controllers (BDC). Students are 
authenticated against these domain controllers with a user name and password. 

The connection itself is a Microsoft version of the Point to Point Protocol (PPP). 
How this protocol works is the basis for many of the protocols in the next section, so it is 
worth further review. 

1. Point to Point Protocol (PPP) 

The PPP protocol is primarily used to allow communication between two 
computers using a serial interface, such as a computer connected to an ISP’s server 
(Whatis?com, “Point-to-Point Protocol”, 25 November 2000). It is a layered protocol, 
starting with a Link Control Protocol (LCP) for link establishment, configuration, and 
testing. This is followed by the Network Control Protocol (NCP) that is used to transport 
traffic between the hosts. The PPP protocol allows for the assignment of an IP address to 
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the remote host, as well as an ability to authenticate the end user. (“Connected: An 
Internet Encyclopedia,” 25 November 2000) 


Since this section is mainly concerned with how NPS users use Microsoft’s ability 
to connect via a PPP session, a review how Microsoft has implemented the protocol will 
be conducted. The following paragraphs on PPP and its four phases are taken from 
“Microsoft’s White Paper on Virtual Private Networking: An Overview.” 

PPP encapsulates network protocols such as IP, IPX, and NetBEUI within PPP 
frames and then transmits those PPP frames across a point-to-point link. This happens in 
four phases. 

a. Phase 1: PPP Link Establishment 

PPP uses a Link Control Protocol (LCP) to establish, maintain, and end 
the physical connection. During this phase, basic communication options are selected, 
including what method of authentication will be used in phase 2. Also negotiated are 
what, if any, forms of compression and/or encryption will be used during the session. 

b. Phase 2: User Authentication 

In the second phase, a user presents their credentials to the remote access 
server. Most PPP implementations are limited to two types of authentication. Password 
Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol 
(CHAP), but Microsoft has implemented and additional protocol called Microsoft 
Challenge Handshake Authentication Protocol (MS-CHAP). 
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• PAP is a simple, clear text authentication implementation. The 
Network Access Server (NAS) requests the user’s name and password 
and PAP passes them in clear text form to the NAS. 

• CHAP is an encrypted authentication implementation that avoids 
transmitting the actual clear-text password by using a hash. The NAS 
sends a challenge consisting of a session ID-and an arbitrary challenge 
string to the remote host. The host must use the MD5 hashing 
algorithm on a concatenation of the challenge string, session ID, and 
the users password, and then sends that hash with the user name back 
to the NAS. The NAS then looks up the user’s password, hashes it 
with the challenge and session ID and compares the hash values. 

• MS-CHAP is very similar to CHAP, except it uses an MD4 hash on 
the challenge string, the session ID, and an already MD4 hashed 
password. The password is hashed on its own before being used as an 
input into the final hash for transport because the server does not keep 
a copy of the clear text password, but instead has a copy of an MD4 
hash of the password. This leads to greater security, since passwords 
are never stored in the clear. The NAS gets its copy of the hash from 
either a PDC or RADIUS server. Also noteworthy is that both the 
client and NAS can independently generate an initial key for 
subsequent data encryption via Microsoft’s Point-to-Point Encryption 
(MPPE). 
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c. 


Phase 3: PPP Callback Control 


Microsoft’s implementation of PPP includes an optional callback control 
phase, where after authenticating, both ends disconnect, and the NAS calls the remote 
host back at a specified phone number. 

d. Phase 4: Invoking Netn'ork Layer Protocol(s) 

At this point, PPP invokes various Network Control Protocols (NCPs) that 
were selected during the link establishment phase to configure the protocols the hosts will 
use to communicate. An example of these protocols might be the IP Control Protocol 
(EPCP) that is invoked to dynamically assign an IP address to the remote host system. 

Once the four phases of the negotiation have completed, PPP begins to forward 
data to and from the two peers. Each packet subsequent to the negotiation is wrapped in 
a PPP header, which is removed by the receiving system, and decompressed and/or 
decrypted. The use of the PPP encapsulation then acts just like any other data link layer 
protocol, such as Ethernet of SONET. (Microsoft, 1999) 


C. ADDITIONAL METHODS TO REMOTELY ACCESS THE INTRANET 

This section covers broadband remote access methods. It is intended to serve as 
an introduction and overview to some of the available methods being used for remote 
access, not as an in-depth analysis of each. It is the author’s intent that these overviews 
will lead to a general understanding of how the methods work, allowing the reader to 
pursue other resources once a choice in methodology is made. 
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1. Point-to-Point Tunneling Protocol (PPTP) 
a. Overview 

PPTP was designed to allow hosts to connect to a RAS server from 
anywhere on the Internet and yet still have the same authentication and access to the 
corporate LAN as if they were dialing directly into a RAS server. But instead of directly 
dialing the network, end users dial into their ISPs to connect to the Internet and then use 
PPTP to set up a secure connection to their RAS server over the Internet. PPTP then acts 
as a tunneling protocol, first encapsulating the network protocol datagrams (including 
such protocols as TCP/IP, NetBEUI, IPX/SPX) within an IP envelope, and then 
encapsulating that packet in a PPP envelope for transmission to the ISP. This establishes 
the VPN, allowing for the secure remote access via your ISP. The only difference with 
broadband access is that there is no need to encapsulate the IP packet within a PPP 
packet, since broadband utilizes an IP connection to the ISP. Also noteworthy is that 
PPTP was designed to use the existing PPP infrastructure, thus gaining the advantages of 
the PPP protocol, including dynamic address assignment from a Dynamic Host 
Configuration Protocol (DHCP) server residing on the secured network, user-based 
authentication, and compression. (Scott, Wolfe, and Erwin, pp. 62-65) 

PPTP was jointly developed by Ascend Communications, U. S. Robotics, 
3Com, ECI Communications, and Microsoft Corporation. Its main purpose was to 
provide a virtual private network between remote access users and network servers. Like 
other tunneling protocols, PPTP is used to tunnel PPP, an OSI layer 2 protocol, which 
operates at the Data Link Layer, via IP at layer 3, known as the Networking Layer. User 
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authentication can take place via either PAP or CHAP, and encryption uses the RC4 
cipher with either 40-bit or 128-bit keys. (Scott, Wolfe, and Erwin, pp. 62-65) 

The PPTP encapsulation protocol is based upon the Internet standard 
Genetic Routing Encapsulation (GRE) protocol, detailed in RFCs 1701 and 1702. The 
PPTP packet is comprised of four parts: the delivery header, an IP header, a GREv2 
header, and the PPP payload packet. The delivery header is. the framing protocol for the 
medium the packet is traversing over, such as Ethernet, Frame Relay, or PPP. The IP 
header contains the required IP information, such as source and destination addresses, 
and packet length. The GREv2 header contains the information on the encapsulation 
method used, as well as any PPTP specific data the host or server may require. Lastly, 
the payload packet contains the encapsulated PPP datagram itself. (Scott, Wolfe, and 
Erwin, p. 70) 
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The actual encapsulation process takes place in four steps. In the first 
step, the end user dials in to his ISP, utilizing a PPP session. All data that is transmitted 
between the user and ISP will be surrounded in a PPP protocol frame. In the second step, 
the end user starts a PPTP connection with the RAS server that is internal to the corporate 
LAN, or intranet. Now the data will not only be encapsulated in a PPP protocol frame, 
but it will also be surrounded, by, the four parts of the PPTP, packet describe, in the 
previous paragraph. The third step involves the RAS server stripping off the delivery 
header, the IP header, the GREv2 header info, and validating the PPP client before 
initiating the last step of removing the PPP framing from the PPP payload packet and 
reformatting the packet with the appropriate medium frame for the corporate LAN. 
(Scott, Wolfe, and Erwin, pp. 70-71) 

b. Microsoft's Implementation of PPTP 

Microsoft has been the leader in deploying PPTP and because of their 
huge product-placement advantage, as well as the Navy’s dedication to the NT platform 
for its IT21 standard, additional Microsoft specifics will be reviewed. 

The Microsoft operating systems come with VPN capabilities inherent in 
the operating system. Windows 95, 98, NT and 2000 all support Microsoft’s 
implementation of PPTP. In these versions, Microsoft has implemented the algorithms 
and protocols in their own unique way, and called the implementation Microsoft PPTP. 
The authentication protocol is the Microsoft Challenge/Reply Handshake Protocol (MS- 
CHAP) and the encryption protocol is called Microsoft Point-to-Point Encryption 
(MPPE). It should be noted that the combined protocols are referred to as MS-CHAP, 
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and it is on its second revision, MS-CHAPv2, after receiving significant criticism of their 
implementation of their initial version. (Schneier and Mudge, p. 1) 

As noted, Microsoft’s first version of MS-CHAP received significant 
criticism from network security companies such as Counterpane and LOpht. These 
reviews left the industry with a belief that PPTP, though a solid concept, was too poorly 
implemented by Microsoft and should not be deployed on any network. But with MSr 
CHAPv2, both Counterpane and LOpht agreed that the changes did correct the major 
security weaknesses. (Schneier and Mudge, p. 2) 

The following is the list of steps Windows uses to create a PPTP VPN, 
and is taken directly from Bruce Schneier and Mudge’s paper on MS-CHAPv2: 

(1) Client requests a login challenge from the Server. 

(2) The Server sends back a 16-byte random challenge. 

(3a) The Client generates a random 16-byte number, 

called the "Peer Authenticator Challenge." 

(3b) The Client generates an 8-byte challenge by hashing 
the 16-byte challenge received in step (2), the 16-byte Peer Authenticator 
Challenge generated in step (3a), and the Client's username. 

(3 c) The Client creates a 24-byte reply, using the 

Windows NT hash function and the 8-byte challenge generated in step 
(3b). 

(3d) The Client sends the Server the results of steps (3a) 

and (3 c). 

(4a) The Server uses the hashes of the Client's password, 
stored in a database, to decrypt the replies. If the decrypted blocks match 
the challenge, the Client is authenticated. 

(4b) The Server uses the 16-byte Peer Authenticator 
Challenge from the client, as well as the Client's hashed password, to 
create a 20-byte "Authenticator Response." 

(5) The Client also computes the Authenticator 
Response. If the computed response matches the received response, the 
Server is authenticated. 
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The largest remaining concern for MS-CHAPv2 is the use of a client’s 
password as an input to creating the shared secret key for the encryption that takes place 
between server and host. “The keys are still a function of the password, and hence 
contain no more entropy than the password. Even though the RC4 algorithm may 
theoretically have 128-bits of entropy, the actual password used for key generation have 
much less” (Schneier and Mudge, p. 7). Ron,Cully, Microsoft’s Senior Product Manager 
for Windows Networking, asserted that the risk of using passwords can be minimized 
through a sound password policy. (Raikow, p. 2) 

Microsoft does not plan on incorporating any additional VPN protocols 
into its Windows 95, 98, or NT product lines, and will continue to support PPTP as well 
as introducing L2TP with IPSec in Windows 2000. Microsoft states its reasoning for 
continued support of PPTP is to allow the ability to create VPNs for customers who do 
not wish to maintain the public key infrastructure required for IPSec (Scott, Wolfe, and 
Erwin, p. 63). 

c. Advantages of PPTP 

A quick summary of advantages of PPTP include: 

• Ease of implementation, with no additional hardware required if a 
company is already a Windows shop. 

• No need to implement IPSec, including not having to manage 
certificates or shared secret keys. 

• Cross platform implementations available from such third parties as 
Efficient Networks, Inc. These products not only allow Macintosh as 
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well as PC access to the network, but also improve the security found 
in Microsoft’s PPTP. 

• Since PPTP uses IP, there should not be any problems with ISP 
conflicts that can happen with IPSec, such as not passing IP Protocol 
50 traffic. 

• Changes to the existing network are minimal, including the opening of 
the PPTP well known port 1723, verses having to reconfigure the 
entire firewall with additional VPN software, or install an additional 
gateway appliance. 

• PPTP also works exceptionally well with Network Address 
Translation. 

d. Disadvantages of PPTP 

Disadvantages to PPTP include: 

• Since MS-CHAPv2 still bases encryption on a user’s password, poorly 
implemented password policy and poor passwords can make the 
system more vulnerable to attack. 

• Implementation does require opening an additional firewall port. 

• Key length is either 40-bits or 128-bits, no longer. 

• MS-CHAPvl is still available, so a concerted effort would need to be 
made to ensure clients used only version 2. 

• Since PPTP’s primary goal is connectivity via tunneling, security is a 
secondary priority. 
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• Older Window’s solutions (95/98/NT) have not scaled well to larger 
numbers (50+) (Brenton and Elfering, p. 37). 

• Can lead to interoperability problems when used with other systems, 
such as may be found between different countries and different allies 
in a military situation. 

2. Layer 2 Tunneling Protocol (L2TP) 
cl Overview 

L2TP is a combination of the PPTP protocol and Cisco System’s Layer 2 
Forwarding (L2F) protocol. It is similar to PPTP in that it relies on PPP to establish the 
dial-up connection, but unlike PPTP, it defines its own tunneling protocol with use of its 
own message types. It uses the PPP, PAP and CHAP for authentication, and because it’s 
a layer 2 protocol, it allows for the transportation of non-IP protocols. It is also media 
independent, so it works over ATM, Frame Relay, or IP. (Brown, pp. 283-284) 

The setup of a VPN with L2TP is also similar to how PPTP sets up. The 
data packet includes the PPP communications. It is also able to use PPP for encrypting 
the packets. (Brown, pp. 283-284) 

The actual communication takes place between a L2TP Network Server 
(LNS) and an L2TP Access Concentrator (LAC), which allows for multiple connections 
inside an individual tunnel by assigning a unique Call ID to each session. L2TP then 
utilizes message types to communicate. Control messages are responsible for session 
management, including establishing and tearing down the session. These messages are 
also used to control the characteristics within the tunnel, including flow control, 
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transmission rates, and buffering of the PPP packets. Data messages are the other type of 
messages used by L2TP and consist of the PPP packets with the framing information. 
(Brown, pp. 283-284) 

b. Microsoft’s Implementation ofL2TP 

As previously stated, with Microsoft being the industrial leader in home 
and business operating systems, and the Navy’s dedication to the IT21 NT standard, 
Microsoft’s implementation of L2TP is also worthy of review. 

In its Windows 2000 product line, Microsoft has expanded its VPN 
implementation with the introduction of L2TP/IPSec. They have integrated the 
technology into Windows 2000 in order to provide an additional method of secure, low 
cost remote access; designing this product to inter-operate with other VPN software and 
devices that support Internet industry standards. In that vein, Microsoft promotes the 
L2TP/IPSec combination as the only standards-track technology that addresses advanced 
security as well as user authentication and DHCP address assignment; all other non- 
L2TP/IPSec implementations of user authentication and address assignments are non¬ 
standard, proprietary implementations that should be avoided. (Microsoft, Windows 
2000-Based Virtual Private Networking: Supporting VPN Interoperability, p. 2) 

IPSec tunnel mode, as defined by the standards, does not support legacy 
user authentication methods (PAP and CHAP), DHCP tunnel IP address assignment and 
configuration, and multiple protocols. So to provide truly interoperable solutions, 
Windows 2000 uses L2TP in combination with IPSec to provide interoperability. By 
placing the L2TP as a payload within an IPSec packet, communications then benefit from 
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the standards-based encryption, integrity and protection of IPSec, while also benefiting 
from user authentication, tunnel address assignment and configuration, and multiple 
protocol support of PPP-based tunneling. (Microsoft, Windows 2000-Based Virtual 
Private Networking: Supporting VPN Interoperability, p. 3) 

IPSec tunnel mode in its original specification only supports 

authentication via user certificates or pre,-shared secret passwords. When IPSec is 

combined with L2TP, it allows for additional methods of user authentication. L2TP uses 
PPP as the method of negotiating user authentication, therefore allowing for the use of 
PAP, CHAP, and MS-CHAP for user authentication. It can also support advanced 
authentication services through Extensible Authentication Protocol (EAP), which can be 
used to provide plug-in authentication services within the L2TP encrypted packet within 
the IPSec packet. This allows for the integration of those extended authentication 
services such as RADIUS and LDAP via the accepted standards instead of in a 
proprietary way. (Microsoft, Windows 2000-Based Virtual Private Networking: 
Supporting VPN Interoperability, p. 5) 

Microsoft is dedicated to only using L2TP with IPSec as the native 
Windows 2000 VPN IPSec solution. It will also continue to support PPTP in Windows 
2000 for those implementations that require the use of non-IPSec solutions, 
c. Advantages of L2TP 
A quick summary of advantages of L2TP include: 

• Ease of implementation, with no additional hardware required if a 
company is already a Windows shop. 
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• Because of its use of PPP, L2TP can authenticate users with legacy 
password based systems such as PAP, CHAP, and MS-CHAP, as well 
as advanced authentication with EAP. Previous key weakness based 
upon passwords is not an issue, since these packets are wrapped inside 
of an IPSec tunnel, using IKE for symmetric key generation. 

• Changes to the existing network is minimal, including the opening of 
the L2TP well known port 1701, verses having to reconfigure the 
entire firewall with additional VPN software, or install an additional 
gateway appliance. 

• Use of IPSec. 

d Disadvantages of L2TP 

Disadvantages to L2TP include: 

• Need to implement IPSec, including having to manage certificates or 
shared secret keys. 

• Implementation does require opening an additional firewall port. 

• Not compatible with network address translation (NAT). 

• May not scale as well as a dedicated hardware solution such as a VPN 
gateway due to the intensive math required for encryption. In most 
VPN gateways, the hardware is custom designed to perform this 
function, therefore increasing speed and efficiency. 
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3. 


Secure Shell (SSH) 


Though initially used by the UNIX community, SSH is making a new life for 
itself as it is ported to other platforms. Its original purpose was to replace unsecured 
protocols such as remote login (rlogin) used in TELNET, remote procedure call (rpc), 
and remote shell (rsh) used with FTP, which allowed a remote user to communicate and 
send commands back to a server. It Js,reviewed in this thesis because of its, ability to - 
tunnel PPP sessions to create VPNs and because of its growing acceptance as a viable 
option for secure remote access. (Acheson, p. 5) 
a. Overview 

SSH works on a PKI method where public and private keys are generated 
for each host/server combination. This means that in order to use SSH, each host must 
create a set of keys to use with each server. These keys are then used to authenticate a 
host each time it logs onto the server. SSH uses the RSA PKI technology to initialize a 
secure session, and to authenticate the user. (Acheson, pp. 6- 20) 

SSH operates on well-known port TCP/22. When used as a VPN, all 
communication takes place on this port, and if required, is forwarded to other ports once 
decrypted. This is what allows the use of other ports across the tunnel, such as retrieving 
mail with IMAP over port TCP/143. (Brenton and Elfering, p. 69) 

As stated earlier, what is making SSH a viable option for a VPN is not 
necessarily its inherent use on UNIX and Linux systems, but its porting to additional 
platforms such as Microsoft’s Windows and Apple’s Macintosh. A leader in this area is 
SSH Communications Security (www.ssh.comL and they have ported the product to 
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Windows via their SSH Sentinel application. The advantage of such products as these is 
the easy-to-use, step-by-step graphical user interface installation wizards that are used to 
create keys and configure the security policy. Also noteworthy is the ability to operate 
with other vendor’s IPSec gateways and implementations of VPN products. 

b. Advantages of SSH 

A quick summary of advantages of SSH include: 

• User friendly set-up interface. 

. Only well known port 22 and IP is required to be supported by the 
firewall. 

• Cross platform implementations, including www.ssh.com for 
Windows and www.macssh.com for Macintosh. 

• Depending upon the implementation, SSH products can be very 
inexpensive (even free). (Brenton and Elfering, p. 70) 

c. Disadvantages of SSH 

Disadvantages to SSH include: 

• Since authentication is based upon a PKI implementation, key 
management can become cumbersome when keys must be generated 
for every server/host combination. (Acheson, p. 55) 

• The preferred version of SSH is version 2, which is still being 
developed by an IETF work group. Without this finalized standard, 
some implementations are considered buggy. (Acheson, p. 54) 
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• Though PPP over SSH is a viable VPN, other implementations such as 
VPN gateways are usually a more robust VPN solution. 

4. TELNET 

Though considered by some a viable option for remote access, the author of this 
thesis concurs with Steven Brown’s observation that TELNET was designed for general, 
bi-directional, 8-bit, byte-orientated unsecured communications. Security considerations 
were never built into TELNET. It should continue to be used in the context for which it 
was designed: simple communication. As such, it will not be covered in any more depth 
in this thesis. (Brown, pp. 461-462) 

If TELNET is a reader’s desired remote access method, SSH should be 
considered its proper replacement. 

5. VPN Gateway Appliances 

The last category of access methods is the VPN gateway appliance. This is a 
dedicated hardware and/or software solution that resides on the boundary of network and 
is responsible for VPN activities. It can be either integrated via software into a computer 
that already resides on the network, such as in a firewall, or can be a completely separate 
appliance that runs its own operating system. An example of the later solution would be 
a VPN TimeStep Gateway from Alcatel. 

There are advantages and disadvantages to either of these solutions and industry 
experts argue over the merits of each. Some prefer to place more of a burden on a 
component that already exists on the network, such as enabling the VPN software found 
in some firewalls, then to install an additional component on the network. This is so that 
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you do not have to add another piece of equipment that must be managed and because it 
does not introduce one more potential access point for a hacker. But others prefer to 
layer security with multiple components to keep from having a single point of failure, and 
that it is better not to over burden a single piece of equipment. There are also those who 
question how strong a product is if it tries to do too much and be an all in one solution. 
Throughout the author’s research, there seemed to be no definitive answers to these 
issues, only many opinions. Two points did seem to be generally agreed upon though. 
The first was to ensure that if you do use an all in one solution, be sure that it does not 
overtax the processing power of that box (i.e. greater then 85-90% of CPU utilization), 
especially since the cryptography function can be extremely math intensive. The second 
was that using a hardware solution for the cryptography, such as found in a VPN gateway 
by Intel or Alcatel, can increase the speed and efficiency of the sessions, since the 
encryption is done by dedicated hardware, not via the software in the OS. 

Whichever gateway appliance implementation is chosen doesn’t matter for this 
review though, since both usually have the same options for how they are configured, 
including the choice of whether to implement IPSec with either a shared secret password 
authentication or through a PKI with a certificate authentication. 

cl IPSec with Shared Secret Authentication 

VPN appliances can be configured with a shared secret password to 
authenticate a host or person. Remember that VPNs can be established between two 
gateways, so it is not always a person who must be authenticated, and that IPSec was 
originally designed to authenticate the host. Therefore, some implementations 
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compliment the initial authentication via a shared secret password with an extended 
authentication mechanism such as RADIUS. This use of XAUTH can either give an 
additional layer of authentication, or can be the primary authentication when a common 
shared secret password is used. What is meant here is that some organizations configure 
their VPN client-ware with an embedded shared secret password, making the software 
the first part of a “what you have, what you know” security, combination.. The second 
part is then the extended authentication of a user name and password via an 
authentication server, such as a RADIUS server. This enables the VPN appliance to be 
configured with only one password making it much easier to manage, and yet still 
ensures security, and authentication via RADIUS. Though this method may seem a bit 
unorthodox, it can be a very viable method for an implementation, as has been proven by 
Bentley College. 

It was during the 1999 PKI and VPN Workshop that Captain Galik, 
Program Manager for Navy Information Systems Security, PMW-161 at SPAWAR, 
touted Bentley’s remote access implementation. So on his recommendation, the author 
visited Bentley College to discuss their implementation and architecture. Bentley’s IT 
department had chosen to configure their Intel/Shiva VPN Gateway in this manner, and 
have found it very effective for over 750 initial test cases, with no security breaches since 
its introduction over a year and half ago. (Interview with Cekanavich) 

The management of the shared secret password becomes the main issue 
with this type of implementation. If an organization chooses to use individual passwords 
for each user, the VPN appliance becomes an additional piece of equipment that must be 
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managed by an administrator, and users are generally required to remember another 
password. This method, though more management intensive, allows for the logging of 
individuals. It also makes it easier if a password has been compromised; only one new 
password must be distributed to a single user. If a common shared secret password is 
used, every piece of client-ware must be updated with the new password, and the 
administrator must find a way to get that new password out to all the users in.a secure 
manner, so it is not intercepted. This can be a major hassle, easily surpassing the initial 
time saved by using only one password. 

The author has been involved with many discussions on this topic of a 
common shared secret key compromise, and it leads to an interesting side note to the 
idea. If you are only using the shared secret password to gain access to the user 
authentication part of the process, is the password any different then the phone number a 
person would use to access a PPP connection. Authentication takes place after the initial 
tunnel is set up with IKE, but before the final SA is established. The password has no 
effect on the final key chosen, since it is created in IKE Quick Mode. So if the password 
is compromised, or even freely distributed, is it really any different than publicizing the 
phone number for a PPP connection? If you trust your Dial-in PPP connection to 
authenticate your users with extended authentication mechanisms such as an NT domain 
controller, or RADIUS as most ISP’s do, then shouldn’t that be enough for the same level 
of access with a different medium, that being broadband? The answer is really up to the 
security manager of the organization, but it is important that these security managers 
consider the possible merits of the argument. 
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b. 


IPSec with Certificate Authentication 


This is the industry’s preferred method of implementation. It is 
management intensive, but also the most robust in its ability to authenticate a user. 
Unlike passwords that may be poorly chosen and easily guessed or gotten through social 
engineering, compromising a certificate requires quite a bit more effort. To compromise 
a certificate takes reverse engineering of the owner’s private key, which is on the order of 
1024 bits, vs. 64 bits found in a 8 byte password. An imposing task to be sure. But this 
security comes at the cost of extensive management of the certificates. This can be done 
in house with an organization’s own certificate server, or contracted out to a third party, 
such as VeriSign. 

Certificates are not without their own problems as well. There are the 
issues of maintaining Certificate Revocation Lists (CRLs), used to publicize an invalid 
certificate, and choosing how CRLs should be used. Are they updated daily and pushed 
to certain servers that will be used for a validity check? Do you sacrifice speed of 
establishing the tunnel so each certificate can be checked against a live CRL at the CA? 
Key escrow is also an issue. If a person chooses to use their keys for encrypting data, and 
that person later leaves the organization due to unforeseen circumstances such as death, 
then how does an organization decrypt what might be vital company data? Does the 
company choose to escrow the private key, and if so, can that key really be considered 
private since there are multiple copies? There is also the issue of how a user stores the 
private key. It could be kept on a specific computer, leading to the question of how does 
one use multiple computers then, or is it kept on a disk which may be lost or stolen? Cost 
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can also be an issue, since using a third party can be very expensive. The list goes on, 
with new issues and answers developing all the time, so it must be left up to the 
individual organization on how best to handle their own situation. 

Either way, with shared secret passwords or certificates, the industry is choosing 
to standardize on IPSec. Like any other maturing standards, there is a period of growth 
where issues are discovered and solutions developed on how to best meet them. For now, 
organizations that choose to adopt technology in its earlier stages, such as VPNs and 
IPSec, must be willing to work with emerging standards. 

c. Placement of the VPN Appliance Relative to a Fir avall 

When working with a VPN appliance, decisions must be made where to 
place it on the border of the network, specifically with regards to the firewall. Issues 
surround each of the following four options, and these will need to be considered by the 
organization before a final decision can be made as to the type and location of the VPN it 
chooses to deploy. 

The first option is to place the VPN within the firewall itself. Many of 
today’s firewall products come with VPN modules that can be installed into the existing 
firewall. As touched upon earlier, this has the advantages of not requiring addition 
equipment and management of an additional box, but may have the disadvantages of 
overtaxing the current system the firewall resides on. This option also depends upon the 
security manager’s view on whether it is better to keep the network access limited to as 
few physical point of entry as possible, or it is better to layer the network with an 
additional security box by installing a separate appliance. This last argument seems to be 
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a glass is half-empty or half-foil issue, being based upon a manager’s preference more 
then any evidence that one is better than the other. 

The second option is to place a separate VPN appliance in front of the 
firewall, between the firewall and the Internet itself. This allows for any traffic that is 
decrypted through the VPN to be checked against the firewall rule base, but also leads to 
certain problems. If you are issuing network IP addresses to your remote VPN clients, 
which most remote VPN clients require, the firewall rule base must be changed to break 
one of the first rules found in a firewall, that internal addresses coming from outside the 
network should not be allowed to pass. This option also means your VPN may also have 
to act as a router, passing all non-VPN data to the firewall. 

The next option is to place the VPN behind the firewall. This limits the 
firewall’s ability to check the packets against its rule base, since packets destined for the 
VPN are encrypted. This can also be an issue if the firewall does not support IP Protocol 
50, ESP, which is its own protocol, not TCP or UDP. If this is the case, the firewall will 
drop the packets instead of being able to pass them. Additional ports will have to open 
on the firewall as well. IKE requires UDP port 500, and if certificates are used on an 
LDAP server, TCP port 389 will also need to be accessible. 

Seeing as how in the last option the firewall has a very limited ability to 
check the VPN packets, some organizations have chosen to place the VPN appliance in 
parallel to the firewall, allowing the screening router to decide which traffic goes to 
which appliance. This overcomes the issues with the placing the VPN either before or 
after the firewall, but still leaves the problem that the traffic is never checked against the 


61 


firewall rule base. In answer to that concern, some security managers believe that since 
the VPN authenticates the users and treats them as if they were already on the network, a 
firewall is not required to protect the network from these outsiders, since they really are 
insiders anyway. Other security managers are placing an additional firewall behind the 
VPN, usually with a smaller rule base since access is limited to users who are already 
authenticated. It should be noted though that this additional firewall means additional 
cost and management, so it may not be right for an organization with limited resources. 

D. ADDITIONAL ISSUES SURROUNDING VPN IMPLEMENTATION 

This section is included to introduce issues that surround a VPN implementation 
that have not yet been covered in the previous sections. It will discuss many of the issues 
that have been discovered by those organizations that have been the early adopters, and 
who have “bled” by being on the cutting edge. The real value of this section is that it 
introduces those issues that have not been well publicized by the industry. 

1. Problems with Internet Service Providers (ISP) 

VPNs are a great tool for accessing that internal network from home, but many of 
today’s ISPs don’t work well with VPNs in general and IPSec specifically. Some ISPs 
who are offering broadband access in the form of cable modems or DSL have found that 
with the advent of VPNs, more of their home users are utilizing their Internet access for 
telecommuting. These selected ISPs are no longer allowing home users to pay the 
residential fee for use of the ISP services if they utilize VPNs. Instead, they are making 
these home users subscribe to a small office home office (SOHO) rate, which is usually 
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quite a bit more money. Other ISPs just will not allow any VPN IPSec traffic. The point 
here is that before a company chooses to establish VPN remote access, it should research 
what ISPs its employees are using, and inform them if they may need to choose another 
provider. 

2. Network Address Translation (NAT) for the Home User 

NAT is a. well-documented problem when used with AH, since, the changing of 
the IP address invalidates the integrity check. However, it is not a problem with ESP, 
which is the most frequent IPSec protocol choice. Other issues with NAT are starting to 
arise though. Many home users are now trying to find ways to share their broadband 
home access among multiple machines in their home, so the spouse and kids can surf on 
their machines while the other host is used for remote access. The problem lies in how 
the home users implement NAT. In addition, some software implementations and home 
routers/firewalls do not work well with IPSec or VPNs. Since these products are 
constantly changing, specifics can not be given here, but the issue should be researched 
by an organization so a home user will know what products are interoperable with NAT 
and the organization’s VPN. 

3. Ensuring that Virus Protection and Home Firewalls are Used 

Once a home computer connects to an intranet via a VPN, it becomes part of that 
network. If that home computer is infected with a virus, or has a Trojan horse residing on 
it, it may make the rest of the network vulnerable to attack. For instance, some Trojan 
horses allow that attacker to take control of a remote host that has been infected. If that 
host connects to the intranet, and is able to be controlled by an attacker, then that attacker 
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has access to the intranet as well. This is a very real problem, but one that can be reduced 
to an acceptable level of risk. What most companies, including the Navy, are doing is 
obtaining site licenses for virus protection programs that include extending the license to 
the home systems of their employees. The company then encourages, or even requires, 
its home users to use this software in order to be able to access the network. This idea 
could, and should, be extended to home firewall products as well. Companies just need « 
to ensure that whatever products are chosen, they are compatible with the VPN (see 
previous section on NAT for more information on this concept). 

4. Split Tunneling 

Some VPN products allow the client-ware to set up a split tunnel. What this does 
is force only the information that is going to the intranet to be encrypted and sent to the 
intranet, while normal Internet traffic is sent directly to the ISP to be routed as normal. 
The concept is desirable, but can be complicated to configure. 

Split tunnels allow users to make a VPN connection to the intranet and perform 
intranet activity, while Internet activity is directed through the ISP, all while still logged 
onto the VPN. The alternative, not utilizing split tunneling, also allows the user to access 
the intranet while logged into the VPN client, but if they want to access the Internet, they 
must either route the Internet traffic through the intranet, or they must log off the VPN 
and directly connect to the Internet via their ISP. The concern from most network 
managers with the alternative is that the home user will log on to the VPN to work, and 
then not log off" when done. This then forces all subsequent personal Internet traffic from 


64 





that host through the internal network, using precious bandwidth when there is no need to 
do so. 


65 



THIS PAGE INTENTIONALLY LEFT BLANK 


66 



IV. CONCLUSIONS 


A. GENERAL COMMENTS 

Eveiy command should be preparing for the inevitable demand for broadband 
access to their intranet. Cable modems and DSL, as well as high-speed wireless access, 
will only proliferate in the coming years. The growing need for real time data, especially 
while away from the “office,” will continue to place a greater demand on network 
manager’s to allow access to their intranets. 

Security of the connection and the data will be at the forefront of the network 
managers concerns. A paradigm shift should be taking place now, understanding that 
trying to secure the “plumbing” of the network becomes unnecessary when data integrity 
and confidentiality are built into the network at the data layer. By securing IP traffic with 
a VPN, there is no longer a need to pay exorbitant prices for dedicated lines, or for other 
means of secure plumbing. Standardizing on IP, with security at the data layer with VPN 
technology, will allow for faster adoption of a secure network technology that can be 
used for everything from data traffic to voice over IP. As IP has become the standard for 
the Internet, VPN technologies should become the standard for securing data that 
traverses a network. 

Because VPN protocols are still in the early phases of design and adoption, 
managers will have to choose which protocols are best for their organization. IP Sec is 
prevailing as the optimum solution, so organizations should plan on implementing it, 
even if other protocols are to be used earlier in the implementation. This means that PKI 
and certificate management should be planned for. The Navy is currently planning for 
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and deploying a proprietary PKI solution, called DoD PKI. It is projected that all end 
users of the Navy will have a certificate by October 2001 (Galik, p. 15). 

B. RECOMMENDATIONS FOR THE NAVAL POSTGRADUATE SCHOOL 

The author’s recommendation for the NPS is that the time is right to implement a 

VPN for broadband access to the intranet. The school can implement the VPN in a 
number of ways, since it is a Microsoft shop, has a firewall capable of being upgraded 
with its own VPN solution, and it has been given a VPN appliance from SPAWAR. The 
school will have to evaluate the different options and decide which is the best fit with 
their network topology, performance requirements, and security perspective. Which ever 
is chosen, a pool of addresses will have to be set aside for DHCP assignment to the 
remote clients, which shouldn’t be a problem for the NPS since it owns the class B 
license of 131.120.X.X. Also, once a chosen method is implemented, NPS needs to 
ensure a standardized configuration for clients is published, as has been done for the 
remote dial-in users with the “NPS Dial-Up E-Mail Remote Access Services (RAS)” 
instruction sheet. 

The assumptions upon which the author based these recommendations involve the 
overall security posture of the NPS campus. The school resides upon an open campus, 
with no restriction for access and no guards on the gates. Most labs remain open during 
working hours, so there is no restricted access to some of the individual computers on the 
campus for most of the day. Intranet access control is therefore based upon the 
authentication mechanisms in Microsoft’s domain controllers and the built-in security of 
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the operating system. Likewise, the domain controllers also control the PPP dial-in 
access for those currently connecting to the intranet remotely. Though it will be up to the 
network and security managers on the campus to decide if any of the following VPN 
implementations meet the current requirements for security, the author believes his 
recommendations are at least as stringent as what is currently in place, if not more secure. 

1. A Microsoft Solution 

A viable option for the NPS is to implement Microsoft’s VPN technology. A 
Windows 2000 Server could be installed and configured to support PPTP connections 
from older Windows 95, 98, and NT clients and L2TP/IPSec connections from the latest 
2000 product line. Actions should be taken to ensure clients only use version 2 of the 
PPTP for the enhanced security reasons mentioned earlier. Authentication will take place 
against the Window’s domain controllers, just as is currently done for the PPP dial-in 
connections. 

NPS’ strong password policy and their continuous checking for weak passwords 
minimize the industry’s concern that PPTP’s use of passwords is unsuitable for key 
generation due to poorly chosen passwords. Because NPS requires passwords of at least 
8 characters in length, with upper and lower case letters combined with digits, the 
passwords used by NPS members are fairly hard to guess, therefore the keys generated 
from them are fairly secure. 
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a. Advantages of a Microsoft Solution 

A quick summary of the advantages of a Microsoft solution include: 

• A quick and simple setup that would not require any additional 
hardware aside from installing Windows 2000 Server on an available 
computer. 

• Use of PPTP does not require the implementation of IPSec. 
Authentication is done with the use of the existing domain controllers. 

• IPSec can be incorporated with Window’s L2TP/IPSec on a trial basis 
with Window’s 2000 clients when the school is ready to implement 
IPSec. 

• No additional client-ware is required for personnel who use the 
Windows operating system. 

b. Disadvantages of a Microsoft Solution 

Disadvantages of a Microsoft solution include: 

• Does not support other operating systems, such as Apple Macintosh 
and Linux, both of which are prevalent in an academic environment 
such as at the NPS. 

• As stated earlier, may not scale well to more then 50 simultaneous 
connections. 

• May be slower than a hardware appliance solution where the 
encryption takes place at the hardware level. 
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• May not be interoperable with other VPNs, such as can be found on 
the NMCI. 

An excellent white paper can be found on the Microsoft web site that contains 
step-by-step instructions on the implementation of the Microsoft solution. It’s entitled 
“Windows 2000 Virtual Private Networking Scenario.” 

2. Upgrading the Current Firewall Product with a VPN Module >. 

During Fiscal Year (FY) 2000, the NPS integrated a new firewall product onto the 
campus intranet. This new firewall was produced by a company call Raptor Inc. It has 
the ability to be upgraded with a VPN solution that uses a client called Mobile. Though 
not a primary consideration in the purchasing decision, it was hoped that the Mobile 
client could be implemented in the future. 

During the last year, a company called Axent bought out Raptor Inc. With this 
purchase, Axent introduced a new VPN solution called PowerVPN, which is a stand¬ 
alone, firewall-independent VPN. With this introduction, Axent has limited its support 
for the Raptor upgraded firewall VPN product and for the Mobile client-ware. (Axent 
Inc.) 

This development makes the use of Mobile client a less attractive alternative, 
though still a viable one. 

a. Advantages of a Upgrading the Current Firewall 

A summary of the advantages of upgrading the current firewall include: 

• As an integrated component, it is designed to work well with the 


current network firewall. 



• No need to purchase additional equipment. 

• No requirement to manage an additional network device. 

• Supports password, NT domain controller, and RADIUS 
authentication (Raptor Inc ). 

b. Disadvantages of a Upgrading the Current Firewall 

Disadvantages of upgrading the current firewall include:. 

• Known not to scale well beyond 5 or 10 simultaneous connections 
(Axent Inc.). 

• Limited support for the product from the parent company. 

• Limited support for different platforms and equipment (Raptor Inc.). 

• Requires the cost of obtaining and installing the upgrade. 

• Limited support for stronger authentication methods (Raptor Inc.). 

3. Installation of a VPN Appliance 

The third option is to install a separate VPN appliance, such as Alcatel’s 
TimeStep VPN appliance, or Axent’s PowerVPN software. This option is by far the most 
complex to install and configure, but it also gives the best performance, scalability, and 
flexibility. It is also this author’s recommended solution. 

This option is favorable over the others for its flexibility and because it will 
ensure interoperability with other components of the NMCI by using the Navy’s chosen 
product, the Alcatel TimeStep solution. This product not only ensures interoperability, it 
also ensure compliance with the DoD PKI model, since Alcatel has committed to 
supporting that proprietary implementation of the PKI. In this specific instance, it also 
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saves NPS the cost of the appliance, since SPAWAR was generous enough to donate a 
TimeStep 7520 box to the school, at a cost of over $10,000. 

The 7520 model supports 70 Mbps of bandwidth, and up to 2000 simultaneous 
connections. The client software runs on all the Window’s operating systems, and 
originally ran on the Mac OS as well, though there is questions as to whether or not they 
will continue support for the Mac. Even if they don’t, third party software developers 
such as Netlock (www.netlock.coml have created interoperable client-ware that will work 
with TimeStep. Alcatel’s solution even supports SWAN, an IPSec and IKE 
implementation for Linux. A site license can also be obtained to freely distribute the 
TimeStep client-ware. 

Until individual certificates are issued by the Navy and DoD PKI is finalized and 
supported by Alcatel, the author recommends using the XAUTH user authentication 
method. As discussed earlier, NPS could set up a single RADIUS server that would 
authenticate clients with the Microsoft domain controllers. Then the TimeStep box could 
be configured to use XAUTH with the RADIUS server. The client-ware could be 
configured with an encrypted IPSec shared secret password, and freely distributed to NPS 
personnel, as was discussed earlier with Bentley College’s implementation. This 
configuration equates to the PPP dial-in method of remote access, with the shared secret 
password gaining the same access to the intranet as the dial-in phone number, with both 
methods then using the domain controllers for authentication of the individual. This 
implementation is better than the PPP dial-in method since it ensures security through 
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data encryption, tunnel security through IKE key generation, and supports broadband 
access. 

If this method of freely distributing a common IPSec shared secret password is 
not a viable option to the network security manager, then the author recommends the use 
of individually assigned passwords. The TimeStep box has the ability to assign 
passwords to individuals for the IPSec authentication section, and then continue to use 
XAUTH for user authentication. This method requires more management for the 
administrator of the TimeStep box. If this method is chosen, it may be better not to 
distribute the client-ware to all personnel, but to issue it on a case by case basis. 

In either case, NPS will still have the ability to transition over to certificates once 
DoD PKI is in place. The TimeStep box can even be used with both types of IPSec 
authentication at the same time, to ease the transition by migrating just a few users at a 
time. 

The author also recommends contacting SPAWAR San Diego for assistance in 
designing and implementing their VPN. The team there has dedicated themselves to 
designing extranets with VPN technology, and are experts in the field. Another team of 
experts can be found at the Marine Corps Network Operations Center (NOC) in 
Quantico, Virginia. This team has already installed these TimeStep VPNs at over 27 
Marine Corps bases, creating one large extranet between them. Alcatel also has a support 
team dedicated to the DoD, and can be contacted via email at 
usdod.support@alcatel.com. 
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a. Advantages of a Using a VPN Appliance 

A summary of the advantages of using a VPN appliance include: 

• A dedicated appliance allows for the greatest level of network design 
flexibility. 

• A hardware appliance, such as a TimeStep gateway, scales well up to 
2000 simultaneous connections. 

• It allows for an IPSec transition from a shared secret password 
authentication to the use of DoD PKI when it becomes available. 

• For the NPS, SPAWAR’s donation of the TimeStep 7520 allows for 
significant cost savings over installing another type of appliance or 
firewall upgrade, and ensures NMCI interoperability. 

• With encryption and decryption at the hardware level, as is done by 
the TimeStep gateway, there will be a significant increase in the speed 
of the connection without overtaxing the gateway, as may happen with 
an upgraded firewall or Microsoft only solution. 

• With the use of a RADIUS server authenticating to the domain 
controllers, the complexity of implementing an authentication 
mechanism is kept to a minimum. 

• Leverages the USN/USMC experience with deployment and 
maintenance issues. 

• OS independent, since it has the ability to support Windows, 
Macintosh, and the UNIX/Linux platforms. 
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b. Disadvantages of a Using a VPN Appliance 
A summary of the disadvantages of using a VPN appliance include: 

• It is the most complex implementation of the available choices. 

• There is increased management with the use of a shared secret IPSec 
authentication method if the shared secret is not freely distributed, or if 
individual passwords are managed on the gateway. 

C. THESIS APPLICATION TO OTHER MILITARY ORGANIZATIONS 

This thesis culminates over a year’s worth of research, including interactions with 
many of the known experts in the field. It should assist readers in building the necessary 
background for designing their own implementation by introducing them to the basic 
concepts and the pitfalls that have been discovered over the last few years. 

With security policy being open to interpretation, it is not possible to make 
specific network design recommendations. This thesis though will allow other 
commands to understand how VPN technology works, and how to design an 
implementation based upon their own requirements. 

It is the author’s hope that this thesis will be of value to those military 
organizations that have an interest in creating a remote access mechanism to their 
intranets. It could be used by any command as a starting point to designing their 
implementation, introducing the concepts and bringing forward those issues of security 
and protocol choices that will need to be selected for their specific implementation. 
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There are a great number of additional resources that can be consulted when 
designing a VPN implementation. Some have already been mentioned in the last 
paragraph of the previous section, which included SPAWAR, USMC NOC, and Alcatel. 
Other resources of course include those found under the References section of the thesis. 
Also available are such organizations as SANS fwww.sans.org ) and VPN Conference and 
Exhibits fwww.vpncon.com') who offer excellent conferences and specific tracts on how. 
to design and implement a VPN. The VPN Consortium (www.vpnc.org') is also an 
excellent place to learn about the latest issue concerning VPNs, including RFCs and other 
current issues. 

D. FUTURE AREAS OF STUDY 

While researching this thesis, the author discovered other collateral areas that 
would be excellent topics for future thesis research. These include: 

• A thorough look into the Navy’s security policies in light of VPN 
technologies. VPNs encompass many new protocols and network design 
issues that need to be evaluated in conjunction with security policy. A Navy¬ 
wide policy recommendation could be the culmination of the research. 

• VPN vulnerabilities need to be researched in conjunction with remote access, 
specifically how to best prevent subversion of remote systems, such as home 
users. 

• The implications IPv6 will have on VPN implementation. 
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E. FINAL COMMENTS 


This final section is dedicated to some final comments that the author hopes will 
help shift some paradigms. The first paradigm is one of bits and security. At a recent 
conference, the author attended a panel discussion where a gentleman stated “Why is it 
that I can trust my entire life’s savings to a 4 digit PIN number with my bank card, but I 
need 1024 bits to check my email securely?” Though there are a lot of reasons based 
upon policy (e.g., limited to $500/day withdrawal) and a bunch of other reasons discussed 
by the panel, it does make one question how much security really is needed? As far as 
the author is concerned, too many people are too concerned with bit length of keys and 
implementations of PPTP, and not enough about what is the value of the data that is 
trying to be protected. In an open campus environment, where a hacker could walk right 
into a school lab, and modems proliferate throughout the campus, is IPSec really 
required? 

The second paradigm deals with “securing the plumbing.” So much time, energy, 
and money is spent trying to ensure that no one can gain access to the network, tap the 
cable, that we lose the idea that if encryption is at the data layer, securing the plumbing 
becomes unnecessary. This concept will become even more important to understand 
when we consider that the age of wireless communications, from phones to broadband, 
will make securing the medium impossible. It needs to be understood that the future lies 
in encrypting objects, such as the datagrams that traverse a VPN, not in securing the 
plumbing. If this concept is combined with a standardization on IP as the protocol, the 
paradigm can truly shift for the DoD to an understanding that the future can lie in all data 


78 



traversing IP with security at the data level, for everything from voice over IP to 
computer data. The value of the data then dictates the security required, and the key 
length that will be needed. 
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